The PACAP Prototype: A Tool for Detecting Java Card Illegal Flow

This paper presents some practical issues of a joint project between Gemplus and ONERA. In this approach, a smart card issuer can verify that a new applet securely interacts with already loaded applets. A security policy has been defined that associates levels to applet attributes and methods and defines authorized flows between levels. We propose a technique based on model checking to verify that actual information flows between applets are authorized. In this paper, we focus on the development of the prototype of the analyzer and we will present the first results. 1. Illegal flow in multi-applicative smart cards Security is always a big concern for smart cards but it is all the more important with multiapplication smart cards and post issuance code downloading. Opposed to mono-applicative smart cards where Operating System (OS) and application were mixed, multi-application smart cards have drawn a clear border between the OS, the virtual machine and the applicative code. In this context, it is necessary to distinguish the security of the card (hardware, operating system and virtual machine) from the security of the application. The card issuer is responsible for the card security and the application provider is responsible for the applet security, which relies necessarily on the card security. The physical security is obtained by the smart card media and its tamper resistance. The security properties that the OS guarantees are the quality of the cryptographic mechanisms (which should be leakage resistant, i.e., resistant against side channel attacks such as Differential Power Analysis), the correctness of memory and I/O management. A Java Card virtual machine relies on the type safety of the Java language to guarantee the innocuousness of an applet with respect to the OS, the virtual machine, and other applets. However, this is ensured by an off-card byte-code verifier, and extra mechanisms that have been added. A secure loader checks before loading an applet that it has been signed (and therefore verified) by an authorised entity (namely the card issuer). Figure 1 shows the role of the different participants. The card issuer or a Trusted Third Party (TTP) is responsible in delivering the certificate indicating the correctness of the verified applet. This verification concerns the type correctness and the card issuer security policy correctness [5]. Card Provider Applet Provider End User Card Issuer Service Provider Applet